1. Field of the Invention
The present invention relates to software testing, and more specifically to a method and apparatus for testing entities such as programs and classes used in object oriented environments.
2. Related Art
A program generally refers to a set of instructions which are written according to a convention specified by a corresponding programming language. Typical programming languages define structures such as program delimiters (e.g., program begin and end), control structures (e.g., if . . . else structure), and loops (e.g., for, while, until structures) using which a developer can develop programs. The programs when executed on a data processing system provide a desired feature.
Programs are often part of what are referred to as classes in object oriented environments (e.g., based on Java programming language). Classes generally contain data structures and associated programs as is well known in the relevant arts. For conciseness, the description below is provided substantially with reference to classes. However, several aspects of the present invention may be implemented outside of object oriented environments.
There has been recognized a need to test classes typically before being used in production environments. Testing generally refers to identifying any problems (defects) in the developed classes. Thus, usually a tester tests the developed objects using testing tools after a developer has developed the programs and/or classes of interest. To facilitate the identification of problems with developed classes, a testing tool may need to support several features.
One desired feature of testing is to ensure that all lines of code are executed at least once so that there can be some level of confidence that a class operates in an intended manner. In one prior approach referred to as ‘stub and driver’ approach, a developer typically designs drivers (a piece of code) which can be used by a tester to invoke different programs on the class being tested with different arguments. The class being tested may invoke other programs on other classes which may not yet be available to the tester. The tester often writes some dummy code to simulate such missing classes that can then be used to test the class of interest. The dummy code is referred to as a stub.
A tester may not be able to determine whether all lines of code of a program are executed using the stub and driver approach usually because of absence of mechanisms to determine whether each line has been executed. In addition, the overhead (usually on the developer) in maintaining the stubs and drivers may not be acceptable in several environments. Accordingly, what is needed is a method and apparatus which enables an easy determination of whether all the program lines of a class have been executed at least once during testing.
Another desirable feature of testing is the ability to provide different argument values (parameters) to each program contained within a class. A tester may use such a feature, for example, to control the program flow or to test a program with different arguments. One type of argument of particular interest is the ability to pass an instance of a class since such a feature simplifies testing of scenarios when an instance of a class is to be provided as an argument to another class.
Yet another desirable feature of testing is the ability to quickly execute pieces of code, not part of the classes being tested, in the middle of testing classes. Such a feature may be used, for example, to examine or store the state of different variables contained within an instance of a class.